Claude的回复，都是我本地跑了然后提交上来的

Claude有个开源项目活动，还差500 star，想要不在更新日志页面/安装页面引导一下来点star 👀

（OpenAI似乎也有相关的活动）

Code Review

整体是一个正确且有价值的修复。核心收益：修了一个真实的旧崩溃——旧 ExtensionMessageConnect.cleanup(con) 在自身 disconnect() 触发时（经 listenerMgr.emit('cleanup') 无参调用）会因 con 为 undefined 在 con.onMessage.removeListener 抛 TypeError，连带导致 chrome 监听器未移除、onDisconnect 不派发；新代码改用 this.con 捕获已彻底修好。onConnect 的首消息去重守卫、MockMessageConnect 的 null-safe 化、gm_api.ts 的 conn→myConn 纯重构均正确。tsc 通过，message 相关测试全绿。

下面是审查发现，按严重度排序。

1. （主要）abort() 路径的 disconnect() 漏跟进 ignoreAlreadyDisconnected=true

src/app/service/content/gm_api/gm_xhr.ts:728

abort: () => {
  if (connect) {
    connect.disconnect();   // ← 未传 true
    connect = null;
  }
  ...

本 PR 给 refCleanup（gm_xhr.ts:309）加了 disconnect(true)，但同一函数内 abort() 的断开点漏改。gm_xhr 没有注册任何 onDisconnect，connect 变量只在 refCleanup（经 onloadend 触发）里才置 null。

触发场景：MV3 service worker 在请求进行中被回收 → content 端口收到 onDisconnect → ExtensionMessageConnect.cleanup 把 this.con 置 null；但因没有 onloadend，connect 变量仍非空。用户脚本随后调用 xhr.abort() → connect.disconnect() → !this.con 命中 → 抛 Attempted to disconnect on a disconnected port.，错误冒泡进用户脚本。

修复：connect.disconnect(true);

2. （主要）GM_download 的 abort() 同样漏改

src/app/service/content/gm_api/gm_api.ts:1192

abort: () => {
  aborted = true;
  connect?.disconnect();   // ← 未传 true；?. 只挡 JS 变量为 null，挡不住底层 this.con 已断开
  nativeAbort?.();
},

该路径的 onDisconnect 回调只调用 releaseResources()（不会把 connect 置 null），所以远端断开后 connect 变量仍非空。下载进行中 SW 重启/扩展更新导致端口断开后，用户调用 abort() 会抛同样的错误。

修复：connect?.disconnect(true);

这两处与本 PR 第 309 行修复的是同一类 bug，建议一并处理，否则修复只覆盖了一半路径。

3. （低/一致性）SW 侧 doLoadEnd 未传 true

src/app/service/service_worker/gm_api/gm_api.ts:790 — myConn?.disconnect() 与本 PR “容忍已断开” 的意图不一致。实际可达性低（同一微任务内 sendMessage(onloadend) 与 disconnect() 同步连续执行，content 来不及在中间断开），几乎不会触发；建议为一致性同样传 true。

4. （外观）三个实现的 disconnect 签名默认值写法不一致

WindowMessageConnect 用 ignoreAlreadyDisconnected: boolean = false，Extension/Mock 用 ?: boolean。行为等价，建议统一。

最值得处理的是 1 / 2。其余改动未发现新引入的缺陷。

fixed in 773b087

可以合并